今天要介紹的Decorator Pattern，跟昨天的Composite Pattern都是屬於Structural Pattern，你可能會發現它們的Class Diagram有點雷同，現在就來認識一下吧！

問題情境與解析

　　現在想像一下，你正在開發一個通知的功能，初始的版本非常簡單，就一個Constructor和一個簡單的送出方法，隨著時間慢慢發展，你的通知功能也許不只是用簡訊通知，可能會用電子郵件或是其他第三方軟體通知，盡可能滿足用戶的需求。

　　後來又有個需求，想要一次不只用一種方式通知，也許是用簡訊加電子郵件，或是用電子郵件加第三方軟體通知，還有可能是一次使用三種不同方式去通知用戶，然而你會為了種種的特殊需求去建立新的子類別來解決問題，但一次一次的增加，便會造成程式碼快速的成長，你需要的是一種方法可以建構這種通知類別的結構，使程式碼膨脹的速度趨緩。

　　Decorator能夠允許在不用改變結構的情況下，對現有的物件添加新的功能，這個模式會創建一個裝飾類別，它將會保持現有類別的結構並增添新的附加功能。

　　也就是說，我們能夠用最簡單的簡訊通知作為基本功能，其他的電子郵件或是第三方軟體的通知一並做成裝飾者，如果想要有不同組合的通知，只要使用裝飾者就可以將簡訊通知的功能額外再添加另一種通知方式囉！

Class Diagram

Skeleton Code

interface Component {
    public void execute();
}

class ConcreteComponent implements Component {
    private Type field;
	
    public ConcreteComponent(Type field) {
        this.field = field;
    }

    public void execute() {
        // Do some work
    }
}

abstract class AbstractDecorator implements Component {
    private Component wrap;

    public AbstractDecorator(Component c) {
        this.wrap = c;
    }

    public void execute() {
        wrap.execute();
    }
}

class ConcreteDecorator extends AbstractDecorator {
    private Type field;
	
    public ConcreteDecorator(Component c) {
        super(c);
    }

    public void execute() {
        wrap.execute();
        extra();
    }

    public void extra() {
        // extra behavior
    }
}

　　Concrete Decorator 和 Concrete Component 都是屬於 Component 型，也就是說，不管是單純的簡訊通知，或是是電子郵件加上第三方軟體通知，對用戶來說都是一種通知而已，不須去耦合如此多類型的通知類別，只要將被包裝的物件給包裝者引用，那麼結果就會是一種不一樣的組合行為。

除此之外，也歡迎大家走走逛逛關於我們團隊夥伴的文章

lu23770127 - SASS 基礎初學三十天

10u1 - 糟了！是世界奇觀！

juck30808 - Python - 數位行銷分析與 Youtube API 教學

SiQing47 - 前端？後端？你早晚都要全端的，何不從現在開始？